NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/2678

Text File | 1996-08-05 | 3.8 KB | 79 lines

Newsgroups: comp.lang.c,gnu.gcc.help
Path: info.physics.utoronto.ca!olivers
From: [e-mail] (Oliver Schonborn)
Subject: Re: [Q] WEIRD macro bug only when compiling with GCC
Message-ID: <[e-mail]>
Nntp-Posting-Host: helios.physics.utoronto.ca
Sender: [e-mail] (System Administrator)
Organization: University of Toronto - Dept. of Physics
Date: Tue, 23 Jan 1996 04:24:22 GMT
References: <[e-mail]> <[e-mail]>

In article <[e-mail]>,
Tanmoy Bhattacharya <[e-mail]> wrote:

>In article <[e-mail]>
>[e-mail] (Oliver Schonborn) writes:
><snip>
>   The macro *works FINE* when I compile with our HP compiler,
>   cc: it prints out one hundred different numbers.  BUT when
>   I use gcc to compile, instead what it prints is double the
>   result of the first SQR on the line, ie  SQR( i*dx, f) * 2.
>   Why isn't (a=b, b*b)+(a=c, c*c) equal to b*b+c*c for GCC?

I meant (a=b, a*a) + (a=c, a*a).

>could happen. There is a rule in C which says that the same object
>cannot be modified more than once without intervening sequence
>points. In your code fragment `a' is modified twice without
>intervening sequence point.
>
>The issue is slightly confusing because the comma does enforce a
>sequence point between the previous and the next expressions:
>i.e. there is a sequence point between a=b and b*b; likewise between
>a=c and c*c. However as the + operator does not enforce _any_ order
>(not even the existence of an order) between its two operands, there
>is no sequence point _between_ a=b and a=c.

Right about the sequence points. I could see that this would be a
problem if I had something like (a=b) + (a=c).  Then the program sets
a=b, but right after sets a to c, so it would yield 2*c (or 2*b if the
compiler first evaluated the right hand side of the + operator).  *But*
here, the result a*a must be stored in some place independent from a,
say a register or some memory location.  The 2 sides of the + operator
are evaluated independently (ie there is no precedence problem between
the + and = and comma), and the comma *is* a sequence point with forced
order from left to right.  Therefore when the program evaluates (a=b,
a*a) (or the other side of the + operator just revert the conclusion
which follows), if first evaluates b, stores it in a, then does a*a and
stores the result somewhere in memory.  Then it evaluates c, stores it
in a (even if a is now changed, it doesn't change the first a*a, since
that is a stored result somewhere in memory), evaluates a*a, and should
store it somewhere *else* in memory, then adds the contents of those 2
memory locations.  So, there should be no problem.  There is no
ambiguity about say, doing first a=b, then a=c, and only after that
doing a*a and again a*a, because of the parentheses.  Or, why would GCC
store the two results (from each side of the + operator) in the same
memory location, just because a*a occurs on both sides of the + operand?

>problem mentioned above, but in addition there is no sequence point
>between the a=c and the first a*a (likewise between the a=b and the
>second a*a).

You must mean something else here, since you just said (and I checked),
that the comma is a sequence point, and not only that, its order is
specified.


So, having read about sequence points, I still think this expression is
valid and unambiguous (assuming b and c don't contain side effects
themselves).  Where is the error?

Thanks,

--
  _________________________________........----------------,
 /\  [e-mail]                            \
 \_|  Condensed-Matter/Quantum-Optics Theory Group           )
   /  Physics Dept University of Toronto -- Canada          /